System and method for providing clinical decision support

ABSTRACT

A system determines patient eligibility for a medical protocol. The system includes a medical protocol library containing information relating to a plurality of medical protocols. The information includes eligibility rules and compliance rules for the plurality of medical protocols. The system also includes a sensor and medical device interface configured to receive patient data from one or more sensors and/or one or more medical device. The patient data relates to the eligibility rules and/or the compliance rules for at least one of the medical protocols. The system also includes a protocol eligibility module configured to determine patient eligibility for at least one of the medical protocols as a function of the received patient data. Furthermore, the system includes a user interface configured to display an indication that the patient is eligible for the protocol.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 63/091,493, filed Oct. 14 2020, U.S. Provisional PatentApplication No. 63/091,427, filed Oct. 14, 2020, U.S. Provisional PatentApplication No. 63/180,881, filed Apr. 28, 2021, U.S. Provisional PatentApplication No. 63/183,979, filed May 4, 2021, and U.S. ProvisionalPatent Application No. 63/190,070, filed May 18, 2021, each of which isincorporated by reference herein in its entirety.

FIELD OF THE INVENTION

Illustrative embodiments of the invention generally relate to systemsand methods for patient monitoring and, more particularly, illustrativeembodiments relate to determining whether a patient qualifies for amedical protocol.

BACKGROUND OF THE INVENTION

Practicing medicine is becoming increasingly more complicated due to theintroduction of new sensors and treatments. As a result, clinicians areconfronted with an avalanche of patient data, which needs to beevaluated and well understood in order to prescribe the optimaltreatment from the multitude of available options, while reducingpatient risks. One environment where this avalanche of information hasbecome increasingly problematic is the Intensive Care Unit (ICU). There,the experience of the attending physician and the physician's ability toassimilate the available physiologic information have a significantimpact on the clinical outcome. Hospitals that do not maintain trainedintensivists around the clock experience a 14.4% mortality rate asopposed to a 6.0% rate for fully staffed centers. It is estimated thatraising the level of care to that of average trained physicians acrossall ICUs can save 160,000 lives and S4.3 Bn annually. As of 2012, thereis a shortage of intensivists, and projections estimate the shortagewill only worsen, reaching a level of 35% by 2020.

The value of experience in critical care can be explained by the factthat clinical data in the ICU is delivered at a rate far greater thaneven the most talented physician can absorb, and studies have shown thaterrors are six times more likely under conditions of informationoverload and eleven time more likely with an acute time shortage.Moreover, treatment decisions in the ICU heavily rely on clinical signsthat are not directly measurable, but are inferred from otherphysiologic information. Thus, clinician expertise and background play amore significant role in the minute to minute decision making process.

SUMMARY OF VARIOUS EMBODIMENTS

In accordance with one embodiment of the invention, a system determinespatient eligibility and compliance with a medical protocol. The systemincludes a medical protocol library containing information relating to aplurality of medical protocol. The information includes eligibilityrules and compliance rules for the plurality of medical protocols. Theplurality of medical protocols may include at least one parent protocoland at least one child protocol. The system further includes a sensorand medical device interface configured to receive patient data from oneor more sensors and/or one or more medical devices. The interface alsoreceives the patient data relating to the eligibility rules and/or thecompliance rules for at least one of the medical protocols. A protocoleligibility module is configured to determine patient eligibility forthe at least one parent protocol as a function of the received patientdata.

A user interface may be configured to display an indication that atleast one patient is eligible for the at least one parent protocol. Thesystem may include a protocol compliance module configured to determine,after the at least one patient enters the parent protocol, a dynamicconcordance rate of the at least one patient for the parent protocol asa function of the received patient data and the compliance rules. Thedynamic concordance rate defines the rate at which the patient data isconsistent with the compliance rules of the parent protocol. Theprotocol eligibility module may be further configured to determinepatient eligibility for the at least one child protocol as a function ofthe dynamic concordance rate of the at least one parent protocol. Theuser interface may also be further configured to display the dynamicconcordance rate of the parent protocol for the at least one patient.

In various embodiments, the user interface is configured to display, inresponse to a user selection of a selected patient, all of the receivedpatient data relating to the eligibility rules and/or the compliancerules of a corresponding protocol that the selected patient is on. Inthe user interface, non-compliant portions of the received data arevisually distinguishable from compliant portions of the data.

The system may work with a plurality of protocols. For example, themedical protocol may be an extubation readiness trial. Patienteligibility for the protocol may be determined as a function of meetinga plurality of conditions and/or patient variables. To that end, theprotocol eligibility module may be configured to determine patienteligibility as a function of a hidden state variable. The eligibilityrules for the child protocol may include a threshold dynamic concordancerate of the parent protocol. Among other things, the protocoleligibility module may be configured to determine patient eligibility asa function of a patient electronic medical record.

The system may also include a quality reporting module configured todetermine a protocol eligibility time. The protocol eligibility time isthe amount of time elapsed from when the at least one patient iseligible for the medical protocol to the time the at least one patientis entered into the medical protocol. In some embodiments, the userinterface is further configured to display the eligibility time for theat least one patient.

In accordance with yet another embodiment, a method enters a patientinto a medical protocol. The method receives eligibility rules andcompliance rules for a plurality of medical protocols. The plurality ofmedical protocols include a parent protocol and a child protocol. Themethod receives real-time patient data from one or more sensors and/ormedical devices. The patient data directly or indirectly relates to theeligibility rules and/or the compliance rules for the parent protocoland/or the child protocol. The method determines that the patient iseligible for the parent protocol as a function of the eligibility rulesand the real-time patient data from the one or more sensor and/ormedical devices. An indication that the patient is eligible for theparent protocol is provided. A dynamic concordance rate for the parentprotocol is calculated. The method determines that the patient iseligible for the child protocol as a function of the dynamic concordancerate of the parent protocol.

The method may also enter the patient into the medical protocol afterindicating that the patient is eligible for the protocol. Additionally,or alternatively, the method may display an indication that the patientis eligible for the protocol. In various embodiments, determiningpatient eligibility is a function of a patient electronic medicalrecord. After determining that the patient is eligible, the method mayautomatically transition the eligible patient into the protocol.

Among other things, the method may display, on a user interface, aplurality of patients that are eligible for the protocol and/orcurrently enrolled in the protocol. The method may also track a timesince the patient became eligible for the protocol and/or a time sincethe patient has been enrolled in the protocol. The method may also tracka dynamic concordance rate of the medical protocol. The time since thepatient became eligible for the protocol, the time since the patient isenrolled in the protocol, and/or the dynamic concordance rate of themedical protocol may be displayed on the user interface.

The method may display, in response to a user selection of a givenprotocol, the received patient data that relates to the eligibilityrules and/or the compliance rules for the selected protocol. Thereceived patient data may be used to determine a hidden state variable.Among other things, the eligibility rules and/or the compliance rulesfor the selected protocol may include a hidden state variable risk.

Illustrative embodiments of the invention are implemented as a computerprogram product having a computer usable medium with computer readableprogram code thereon. The computer readable code may be read andutilized by a computer system in accordance with conventional processes.

BRIEF DESCRIPTION OF THE DRAWINGS

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawing(s) will be provided by the Office upon request and paymentof the necessary fee.

Those skilled in the art should more fully appreciate advantages ofvarious embodiments of the invention from the following “Description ofIllustrative Embodiments,” discussed with reference to the drawingssummarized immediately below.

FIG. 1 schematically shows a clinical patient environment in accordancewith illustrative embodiments of the invention.

FIG. 2 schematically shows details of a system in accordance withillustrative embodiments of the invention.

FIG. 3 schematically shows a notification through which a user mayacknowledge patient eligibility and customize compliance rules inaccordance with illustrative embodiments of the invention.

FIG. 4 schematically shows eligibility rules and compliance rules for anexample of an extubation readiness test protocol in accordance withillustrative embodiments.

FIG. 5 shows a process of determining that the patient is eligible forthe medical protocol in accordance with illustrative embodiments.

FIG. 6 schematically shows a generic example of an executable medicalprotocol configuration having a variety of eligibility rules, compliancerules, and a protocol trigger in accordance with illustrativeembodiments.

FIG. 7 schematically shows an example of a medical protocol for anextubation readiness trial having a variety of eligibility rules,compliance rules, and a protocol trigger in accordance with illustrativeembodiments

FIG. 8 shows a user interface for tracking compliance with the protocolin accordance with illustrative embodiments.

FIG. 9 schematically shows an interface for showing protocol complianceand time on protocol for a plurality of patients in accordance withillustrative embodiments.

FIG. 10 schematically shows a report generated by the quality reportingmodule showing facility wide compliance with protocols in accordancewith illustrative embodiments of the invention.

FIG. 11 shows a process of nesting protocols in accordance withillustrative embodiments.

FIG. 12 schematically shows an example of nested medical protocolshaving a variety of eligibility rules, compliance rules, and a protocoltrigger in accordance with illustrative embodiments.

FIGS. 13A-13G schematically show an interface for viewing patientprotocol information in accordance with illustrative embodiments.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

In illustrative embodiments, a system enables real-time tracking ofpatient eligibility for one or more protocols based on a variety of datarelating to the patient. To that end, the system has access to datarelating to a variety of medical protocols and parameters/rules forpatient eligibility within the protocols. Each protocol is associatedwith a medical procedure, medical treatment, or medical intervention(generally referred to as a course of action). The system automaticallystreams and collects patient data to determine the real-time eligibilityof the patient for the protocol. Prior to initiating a medical course ofaction (also referred to as initiating or beginning the protocol), theduration of eligibility compliance for different variables is tracked ina dynamic manner. After the patient begins a given protocol, the systemtracks protocol compliance for different variables in a dynamic manner.

Illustrative embodiments further enable advanced protocols. For example,some protocols may use risk analytics (e.g., hidden internal statevariables) to determine patient eligibility and/or compliance.Furthermore, illustrative embodiments additionally, or alternatively,enable nested protocols, where compliance with a first protocol (ormore) is an eligibility criterion for a second protocol. Thus, theinventors discovered that new protocols could be created that use thedynamic concordance rate of another protocol as an eligibility and/orcompliance rule.

Illustrative embodiments also provide an interactive display for medicalpractitioners that provides visualization for patient performance on theprotocol. A display provides a listing of all patients under care of themedical practitioner or all patients in a particular unit, and furtherprovides protocol status details for each patient. For example,illustrative embodiments provide visual indications of whether thepatient is eligible for a course of action associated with the protocoland the amount of time the patient has been eligible. If the patient ison a protocol, illustrative embodiments provide visual indications ofhow long the patient has been on the protocol and how compliant thepatient has been with the protocol. Some embodiments may provide avisual indication of the compliance rate per individual parameter of theprotocol for each patient. After selecting the visual indication, adisplay shows the patient performance variables that are relative to theparticular protocol. Details of illustrative embodiments are discussedbelow.

FIG. 1 schematically shows a clinical patient environment in accordancewith illustrative embodiments of the invention. The environment includessensors 102 (also referred to as monitors 102) for providing patientdata to health providers, such as physicians, nurses, or other medicalcare providers. To that end, a patient 101 may be coupled to one or morephysiological sensors 102 or bedside monitors 102 that may monitorvarious physiological parameters of the patient. It should be noted thata patient 101 may be a human, or not human (a non-human being, e.g., adog).

The sensors 102 may include, but are not limited to, a blood oximeter, ablood pressure measurement device, a pulse measurement device, a glucosemeasuring device, one or more analyte measuring devices, anelectrocardiogram recording device, amongst others. In addition, thepatient 101 may be administered routine exams and tests and the data maybe stored in an electronic medical record (EMR) 103 (shown in FIG. 2).The electronic medical record 103 may include but is not limited tostored information such as hemoglobin, arterial and venous oxygencontent, lactic acid, weight, age, sex, ICD-10 code, capillary refilltime, subjective clinician observations, patient self-evaluations,prescribed medications, medications regiments, genetics, test results,allergies, etc.

In addition, the patient 101 may be coupled to one or more treatmentdevices 104 that are configured to administer treatments to the patient.In some embodiments, one or more treatment devices 104 may be controlledby a system 100 as disclosed herein, for example in response to outputdefining a patient state or medical condition from a trajectoryinterpreter module. In various embodiments, the treatment devices 104may include extracorporeal membrane oxygenator, mechanical ventilator,medication infusion pumps, implantable ventricular assist devices, etc.

Illustrative embodiments provide real-time automatic determination ofwhether the patient 101 is eligible for a course of action of themedical protocol (referred to generally as being eligible for theprotocol) based at least partially on data acquired directly from thesensors and peripheral devices. The real-time determination isadvantageous over prior art methods that require the medicalpractitioner to review disparate patient data reports and analyze thedata to determine whether the patient 101 is eligible for the protocol.Additionally, the medical practitioner generally checks patienteligibility sporadically, leading to sub-optimal clinical outcomes incases where optimal medical treatment for the patient 101 requires earlyinitiation of the protocol. In a similar manner, sporadic eligibilitychecks fail to account for the dynamic concordance of the patient'seligibility because the measurements are taken at a static moment intime.

The system 100 may track how long a patient variable has been incompliance with a set eligibility criteria, advantageously improvingmedical protocol technology by enabling new protocols that have alongitudinal (e.g., sustained time basis) criteria, as opposed toprotocols that use the most-recent static data points. Accordingly,illustrative embodiments track dynamic concordance, or the rate at whichpatient physiological data is consistent with the requirements of aprotocol after the protocol is initiated. This advantageously allowsmedical practitioners to visualize the patient data as a percentagecompliance per time duration (e.g., 60% dynamic concordance in the 3hours since protocol began). Furthermore, tracking eligibility timeadvantageously allows medical practitioners to prioritize patients whohave been eligible for a long time, thus mitigating any risk emanatingfrom the fact that they have not been getting the prescribed protocoltreatment for prolonged duration.

The dynamic concordance calculation based on longitudinal measurementsof patient variables also supports using the metric as an actionabletherapeutic target and consequently administering treatment targeted atincreasing the concordance rate of the patient. Furthermore, theinventors have preliminary data indicating that patients achieving adesired dynamic concordance rate may experience better outcomes relativeto patients that have lower concordance rate.

By providing continuous real-time assessment of whether the patienttrajectory is progressing according to a protocol specified pathway, thedynamic concordance affords more focused and timely intervention to keepthe patient within the most advantageous course, which is a significantimprovement relative to what is possible with current technology. Thelonger time the patient spends within the desired trajectory as measuredby the concordance rate the higher is the likelihood that the patientwill not experience complications and achieve the optimal possibleclinical outcome. Conversely, the less time the patient spends withinthe desired trajectory as measured by the concordance rate the higherthe likelihood that the patient will experience complications and notachieve the optimal clinical outcome.

To that end, a patient protocol eligibility and compliance system,generally referred to herein as system 100, may be configured to receivepatient related information, including real-time information from thesensors 102, EMR patient information from the electronic medical record103, information from the treatment devices 104, such as ventilatorysettings, infusion rates, types of medications, and other patientrelated information, which may include the patient's medical history,previous treatment plans, results from previous and present lab work,allergy information, predispositions to various conditions, and anyother information that may be deemed relevant to make.

The system 100 provides real-time protocol eligibility updates.Additionally, illustrative embodiments may determine the extent of timethat the patient 101 is eligible for a protocol. Accordingly, medicalpractitioners may have quantifiable standards by which medicalpractitioner performance is judged (e.g., time from eligibility toprotocol initiation, protocol compliance rate, etc.).

FIG. 2 schematically shows details of the system 100 in accordance withillustrative embodiments of the invention. The system 100 includes asensor/medical device interface 106 configured to communicate with theone or more sensors 102 and/or one or more medical devices 104. Forconvenience, illustrative embodiments may refer to receiving data fromone or more sensors and/or one or more medical devices generally asreceiving data from the sensors 102. However, it should be understoodthat discussion of receiving data from the sensors 102 is intended toalso include receiving data from the medical devices 104.

To reiterate, the interface 106 receives/ streams real-time patient datafrom the sensors 102. The interface 106 may receive data from a varietyof sensors 102, such as blood oximeter, a blood pressure measurementdevice, a pulse measurement device, a glucose measuring device, one ormore analyte measuring devices, an electrocardiogram recording device,amongst others. In some embodiments, the interface 106 simultaneouslycommunicates with a plurality of sensors 102 and/or medical devices.Accordingly, the interface 106 may aggregate and/or compile the variousreceived patient data.

The system 100 includes a database 105 having access to the patient EMR103, as described previously. The database 105 may also communicate withthe sensor interface 106 to store the real-time data as it is receivedvia the interface 106. The system 100 also includes a medical protocollibrary 108 containing information relating to a plurality of medicalprotocols. As an example, the medical protocol may include an extubationreadiness trial protocol, ventilation vasoactive weaning protocol,sepsis management protocol, enhanced recovery after surgery (ERAS)protocols, and/or other hospital protocols. The information in thelibrary 108 includes eligibility rules and compliance rules for each ofthe protocols, which are discussed in more detail further below. Thelibrary 108 may also include specific subscription rules and/ornotification rules for each protocol, which are discussed in more detailfurther below.

A protocol eligibility and compliance module 110 is configured todetermine patient eligibility for at least one of the medical protocolsas a function of the received patient data. Additionally, theeligibility and compliance module 110 may access historic data and/orthe EMR 103 from the database 105 to determine patient eligibility. Tothat end, the eligibility and compliance module 110 may communicatewith, among other things, the interface 106, the database 105, and thelibrary 108.

Generally, patient eligibility depends on one or more measurements ofpatient data meeting a threshold status according to the requirements ofthe protocol stored in the library 108 (e.g., a certain FiO2 and/or BPMmeasurement). When the patient 101 is eligible for a protocol, theeligibility module 110 triggers an indication that the patient 101 iseligible. In some embodiments, the eligibility module 110 sounds analert and/or communicates with a user interface 112 to visually indicatethe patient is eligible. In some embodiments, the user interface alsocommunicates the amount of time the patient has been eligible. Thus,illustrative embodiments advantageously provide real-time updates as topatient eligibility status. The real-time data collection andeligibility updates contrast to prior art methods that rely on medicalpractitioners checking, collecting, aggregating, and analyzing aplurality of static patient parameters to determine protocoleligibility.

The determination of eligibility is based on a collection of measurementthresholds, events, and/or other binary variables. For example,eligibility rules for a vasoactive weaning protocol may include that thepatients are under cardiac service (determined by the hospital ADTstream or EMR), are on medication drip (another event), have IDO2 indexless than a threshold value, and have blood pressure greater thananother threshold value.

The system 100 may include a quality reporting module 114 that tracksthe time elapsed from patient eligibility until a user acknowledgespatient eligibility. FIG. 3 schematically shows a popup notificationthrough which the user may acknowledge patient eligibility (e.g., on atouch screen display via user interface 112) in accordance withillustrative embodiments of the invention. Alternatively, oradditionally, the quality reporting module 114 may track the timeelapsed from patient eligibility until a medical practitioner begins thecourse of action associated with the eligible protocol for the patient101. By tracking this information, medical practitioner performance maybe objectively measured (e.g., which practitioners are the fastestresponders and what are the impacts of fast response time on clinicaloutcomes).

The system 100 may also include a protocol trigger module 116 thatinstructs the eligibility and compliance module 110 to begin trackingpatient 101 compliance data. The protocol trigger module 116 isconfigured to receive information regarding the initiation of a courseof action in the protocol 120. In various embodiments, the medicalpractitioner may initiate the course of action based on the feedbackfrom the eligibility module 110 and inform the protocol trigger module116 (e.g., through the user interface) of the course of actioninitiation. In some embodiments, the protocol trigger module 116 isconfigured to automatically initiate the course of action bycommunicating with a treatment device 104 (e.g., after a medicalpractitioner approves the initiation via the user interface). In otherembodiments, the protocol trigger module 116 can automatically detectthat the practitioner has initiated the course of action and initiatetracking concordance data. For example, in the ERT protocol, when thesystem 100 detects that the ventilator mode has been changed, and thisis used to detect the start of an ERT protocol and triggers dynamicconcordance tracking for the protocol.

After the course of action for the protocol is initiated, theconcordance module 110 may continue to communicate with the same,different, or additional sensors 102 to determine patient 101 compliancewith the protocol. The compliance module 110 may determine thecompliance of the patient 101 with the medical protocol as a function ofnewly received patient data and the compliance rules in the library 108.Compliance is generally determined as a calculation of whether thepatient data meets acceptable levels set by the library 108 for theparticular protocol (e.g., the patient variable is compared to the levelor range required by the library 108). Additionally, the compliancemodule 110 may visually indicate (e.g., via the user interface 112) thereal-time patient dynamic concordance status. FIG. 4 schematically showseligibility rules 122 and compliance rules 124 for an example of anextubation readiness test protocol in accordance with illustrativeembodiments. It should be understood that the tracked parameters foreligibility may differ from the tracked parameters for compliance, asshown in FIG. 4. The concordance module 110 may send the dynamicconcordance rate to the user interface 112, which displays the dynamicconcordance rate. Accordingly, the attention of the medical practitionermay be drawn to the patient in need of action.

The quality reporting module 114 may track a dynamic concordance rate asa percentage of time over which the patient 101 is compliant with themedical protocol and/or the patient eligibility time. Additionally, thequality reporting module 114 may retrospectively look at patientconcordance rate and/or eligibility time to see how well a particularpatient and/or patients of a particular medical practitioner haveperformed relative to a patient population. Additionally, the reportingmodule 114 may be configured to display the received patient data and tomark non-compliant portions of the received data. Thus, the qualityreporting module 114 allows medical facilities and/or staff to evaluatehow well patients were managed retrospectively. For example, ifeligibility times are very high, medical practitioners become aware ofit. This assists with hospital policy formation and also with ensuringprompt action by the medical staff.

The system of FIG. 2 may include a risk-based monitoring engine 1000(also referred to as “risk engine 1000”) configured to receive data frombedside monitors 102, electronic medical records 103, treatment devices104, and any other information that may be deemed relevant to make aninformed assessment regarding the patient's clinical risks, and anycombination thereof of the preceding elements.

In illustrative embodiments, the risk engine 1000 may include aphysiology observer module 119 that utilizes multiple measurements toestimate probability density functions (PDF) of internal state variables(ISVs) that describe the components of the physiology relevant to thepatient treatment and condition in accordance with a predefinedphysiology model. The ISVs may be directly observable with noise (as anon-limiting example, heart rate is a directly observable ISV), hidden(as a non-limiting example, oxygen delivery (DO2) defined as the flow ofblood saturated oxygen through the aorta cannot be directly measured andis thus hidden), or measured intermittently (as a non-limiting example,hemoglobin concentration as measured from Complete Blood Count tests isan intermittently observable ISV).

In some embodiments, when the physiology observer module 119 evaluates aset of ISVs at a given time step (e.g., tk; tk+1; generally tk+n), thesystem 100 may not have a complete set of ISV measurementscontemporaneous with that given time step. For example, the system 100may have measurements for that given time step for some internal statevariables, but may not have measurements for that given time step forsome other internal state variables (e.g., a contemporaneous measurementfor an intermittent ISV may not be available for the given time step).Consequently, that intermittent ISV is, for purposes of evaluating ISVsat the given time step, a hidden ISV. However, evaluation of the set ofISVs by the physiology observer module 119 (as described herein) isnevertheless possible according to embodiments described herein becausethe predicted PDFs of ISVs 211 carry in them the influence of pastmeasurements of that intermittent ISV, and consequently those predictedPDFs of ISVs 211 are, in illustrative embodiments, sufficient input forthe physiology observer module 119.

In one embodiment, instead of assuming that all variables can beestimated deterministically without error, the physiology observermodule 119 of the present disclosure provides probability densityfunctions as an output. Additional details related to the physiologyobserver module 119 are provided herein.

The clinical trajectory interpreter module 123 may be configured, forexample, with multiple possible patient states, and may determine whichof those patient states are probable and with what probability, giventhe estimated probability density functions of the internal statevariables. Examples of particular patient states include, but are notlimited to, hypotension with sinus tachycardia, hypoxia with myocardialdepression, compensated circulatory shock, cardiac arrest, hemorrhage,amongst others. In addition, these patient states may be specific to aparticular medical condition, and the bounds of each of the patientstates may be defined by threshold values of various physiologicalvariables and data. In various embodiments, the clinical trajectoryinterpreter module 123 may determine the patient conditions under whicha patient may be categorized using any of information gathered fromreference materials, information provided by health care providers,other sources of information.

The reference materials may be stored in the database 105 or otherstorage device that is accessible to the risk-based monitoringapplication 1020 via network interface 113, for example. These referencematerials may include material synthesized from reference books, medicalliterature, surveys of experts, physician provided information, and anyother material that may be used as a reference for providing medicalcare to patients. In some embodiments, the clinical trajectoryinterpreter module 123 may first identify a patient population that issimilar to the subject patient being monitored. By doing so, theclinical trajectory interpreter module 123 may be able to use relevanthistorical data based on the identified patient population to helpdetermine the possible patient states.

The clinical trajectory interpreter module 123 is capable of alsodetermining the probable patient states under which the patient can becurrently categorized, given the estimated probability density functionsof the internal state variables, as provided by physiology observermodule 122. In this way, each of the possible patient states is assigneda probability value from 0 to 1. The combination of patient states andtheir probabilities is defined as the clinical risk to the patient.

Each of the above-described components is operatively connected by anyconventional interconnect mechanism. FIG. 2 simply shows a buscommunicating each of the components. Those skilled in the art shouldunderstand that this generalized representation can be modified toinclude other conventional direct or indirect connections. Accordingly,discussion of a bus is not intended to limit various embodiments.

Indeed, it should be noted that FIG. 2 only schematically shows each ofthese components. Those skilled in the art should understand that eachof these components can be implemented in a variety of conventionalmanners, such as by using hardware, software, or a combination ofhardware and software, across one or more other functional components.For example, the quality reporting module 114 may be implemented using aplurality of microprocessors executing firmware. As another example, theprotocol eligibility and compliance module 110 may be implemented usingone or more application specific integrated circuits (i.e., “ASICs”) andrelated software, or a combination of ASICs, discrete electroniccomponents (e.g., transistors), and microprocessors. Accordingly, therepresentation of the components in a single box of FIG. 2 is forsimplicity purposes only.

In some embodiments, components of the system may be separated intodifferent components. For example, the protocol eligibility andcompliance module may be split into two different modules, e.g., aprotocol eligibility module and a protocol compliance module.Additionally, various components, such as the sensor/medical deviceinterface 106 of FIG. 2, may be distributed across a plurality ofdifferent machines—not necessarily within the same housing or chassis.

Additionally, in some embodiments, components shown as separate (such asthe eligibility and compliance module 110 and the quality reportingmodule 114 in FIG. 2) may be replaced by a single component.Illustrative embodiments may include additional modules not explicitlyshown here. Furthermore, certain components and sub-components in FIG. 2are optional. For example, some embodiments may not include the protocoltrigger module 116.

It should be reiterated that the representation of FIG. 2 is asignificantly simplified representation of the system 100. Those skilledin the art should understand that such a device may have other physicaland functional components, such as central processing units, otherpacket processing modules, and short-term memory. Indeed, the system100, in various embodiments, includes one or more of the following: aprocessor, a memory coupled to the processor, and a network interfaceconfigured to enable the system to communicate with other devices over anetwork. In addition, the system may include a risk-based monitoringapplication 1020 that may include computer-executable instructions,which when executed by the processor 111, cause the system to be able toafford risk-based monitoring of the patients, such as the patient101.Accordingly, this discussion is not intended to suggest that FIG. 2represents all of the elements of the system 100.

FIG. 5 shows a process 500 of determining that the patient 101 iseligible for the medical protocol. It should be noted that this processcan be a simplified version of a more complex process that may normallybe used. As such, the process may have additional steps that are notdiscussed. In addition, some steps may be optional, performed in adifferent order, or in parallel with each other. Accordingly, discussionof this process is illustrative and not intended to limit variousembodiments of the invention. Finally, although this process isdiscussed with regard to entering a single patient in a medicalprotocol, the process of FIG. 5 can be expanded to cover processes forentering a plurality of patients in one or more medical protocols at thesame time. Accordingly, the process 500 is merely exemplary of oneprocess in accordance with illustrative embodiments of the invention.Those skilled in the art therefore can modify the process asappropriate.

The process begins at step 502, which receives eligibility rules andcompliance rules for one or more protocols. In illustrative embodiments,the eligibility rules and compliance rules are received from the medicalprotocol library 108. As described previously, the protocol library 108contains information relating to a plurality of medical protocols.

FIG. 6 schematically shows a generic example of a medical protocol 120having a variety of eligibility rules 122, compliance rules 124, aprotocol trigger 126, subscription rules 128, and notification rules 130in accordance with illustrative embodiments. Although the eligibilityrules 122, the compliance rules 124, the protocol trigger 126,subscription rules 128, and the notification rules 130 are shown asbeing part of a single protocol 120, in some embodiments, the protocoleligibility rules 122, the compliance rules 124, the protocol trigger126, subscription rules 128, and/or the notification rules 130 may bereceived at different times within the process 500 of FIG. 5.Additionally, in some embodiments, the medical protocol 120 may notinclude subscription rules 128, the notification rules 130, thecompliance rules 124 and/or the protocol triggers 126.

The eligibility rules 122 may include one or more conditions that mustbe satisfied (e.g., true or false) for the patient 101 to be eligiblefor the protocol 120. The eligibility module 110 may compare data in thedatabase 105 and/or EMR 103 with the rules 122 to determine whether therules 122 are met. Additionally, or alternatively, the eligibility rules122 may include one or more parametric conditions that must be satisfied(e.g., a certain variable is greater than a particular value). Theeligibility module 110 may receive patient data 106 from the interface106 to determine whether the patient 101 is eligible (e.g., the rules122 are satisfied).

In a similar manner, the compliance rules 124 may include a variety ofconditions that must be satisfied (e.g., true or false) for the patient101 to be in compliance with the protocol 120. The compliance module 110may compare data in the database 105 and/or EMR 103 with the rules 122to determine whether the rules 122 are met. Additionally, oralternatively, the compliance rules 124 may include a variety ofparametric conditions that must be satisfied (e.g., a certain variableis greater than a particular value). The compliance module 110 mayreceive patient data 106 from the interface 106 to determine whether thepatient is in compliance with the protocol 120 (e.g., the rules 124 aresatisfied).

Furthermore, in some embodiments the protocol 120 may define a protocoltrigger 126 that includes one or more conditions that automaticallytrigger the course of action to begin when satisfied. In someembodiments, the conditions may include a dynamic concordance rate ofthe given protocol or of a parent protocol. The protocol trigger module116 may detect when these conditions are satisfied, and may communicatewith and/or control one or more medical devices 104 to begin the courseof action. Additionally, or alternatively, the protocol trigger module116 may receive an indication (e.g., from a medical device 104 or from amedical practitioner through the user interface) that instructs theprotocol trigger module 116 to activate the compliance module 110. Thecompliance module 110 then begins to track dynamic concordance.

In various embodiments, the protocol 120 may further includesubscription rules 128 and notification rules 130. The subscriptionrules 128 assign different subscription levels to different medicalpractitioners. For example, the direct care team may be subscriptionlevel 1, whereas the management team by may be subscription level 2. Thesubscription rules 128 may be used in the notification rules 130.Accordingly, different subscriptions may receive different notificationsand/or notifications for different reasons.

The process then proceeds to step 504, which receives patient datadirectly or indirectly. The patient data may be received directly (e.g.,streamed) in real-time from the sensors 102 and/or medical devices. Thepatient data may include internal state variables (or “ISV”), which areparameters of the patient's physiology that is physiologically relevantto treatment and/or a condition of a patient. ISVs may be directlyobservable with noise (as a non-limiting example, heart rate is adirectly observable ISV), hidden (as a non-limiting example, oxygendelivery (DO2) defined as the flow of blood saturated oxygen through theaorta cannot be directly measured and is thus hidden), or measuredintermittently (as a non-limiting example, hemoglobin concentration asmeasured from Complete Blood Count tests is an intermittently observableISV). Other examples of ISVs include, without limitation, PulmonaryVascular Resistance (PVR); Cardiac Output (CO); hemoglobin, and rate ofhemoglobin production/loss.

Additionally, in some embodiments, the relevant patient data may beindirectly received (e.g., may not be directly observable/measurable). Ahidden Internal State Variable, means an ISV that is not directlymeasured by the sensor 102 coupled to the patient 101. Some hidden ISVscannot be directly measured by the sensor. In some embodiments, themodule may receive, in addition to or instead of sensor data, datarepresenting a risk that the patient is suffering a specific adversemedical condition as indicated by the probability of the hidden internalstate variable being in a particular state. Some hidden ISVs require,for example, laboratory analysis of a sample (e.g., blood) taken fromthe patient. Additional details regarding hidden internal statevariables are described in U.S. patent application Ser. No. 17/033,591,which is incorporated herein by reference in its entirety.

Among other things, the received patient data may include: expired CO2,end-tidal CO2 measurement (EtCO2), arterial CO2, minute ventilation,ventilator mode, drug infusion rate, respiratory rate, PaCO2 arterialblood gases, Hb Hemoglobin, HR Heart Rate, SpvO2 Pulmonary Venous OxygenSaturation, SaO2 Arterial Oxygen Saturation, SvO2 Systemic Venous OxygenSaturation, SpO2 Pulmonary Venous Oxygen Saturation, Mean Arterial BloodPressure, Central Venous Pressure, Left Atrial Pressure, Right AtrialPressure, patient weight, patient age, patient height, and/or patientmedical history.

Returning to FIG. 5, the process proceeds to step 506, which determineswhether the patient 101 is eligible for the protocol 120. The protocoleligibility and compliance module 110 compares the various patient datawith the eligibility rules 122 to determine whether the patient 101 iseligible for the protocol 120.

FIG. 7 schematically shows an example of a medical protocol 120 for anextubation readiness trial having a variety of eligibility rules 122,compliance rules 124, and a protocol trigger 126 in accordance withillustrative embodiments. In this example, the eligibility rules 122have three conditions: (1) FiO2 must be less than or equal to 0.5, (2)PEEP must be less than 7 cm H₂O, and (3) the patient must bemechanically ventilated. If any of these three conditions is notsatisfied, then the process returns to step 504, which continues toreceive patient data.

Alternatively, if the eligibility rules 122 are satisfied, then theprocess optionally proceeds to step 508, which tracks the eligibilitytime. In illustrative embodiments, the quality reporting module 114tracks the time at which the patient 101 became eligible for theprotocol 120, and the duration from the eligibility time to apredetermined event. The predetermined event may be, for example, when amedical practitioner acknowledges patient eligibility (e.g., popupnotification on touch screen display via user interface 112), or whenthe course of action for the eligible protocol is initiated. FIG. 3schematically shows a popup notification on the touch screen indicatingthat the user is ready to start the protocol. Additionally, oralternatively, the system 100 can automatically detect received datafrom a peripheral device associated with the course of action, e.g. amechanical ventilator, and determine that the medical practitioner hasinitiated the course of action associated with the protocol, (e.g. theventilator setting has been transitioned).

The process then proceeds to step 510, which initiates the course ofaction associated with the protocol (also referred to as entering thepatient 101 into the protocol). In some embodiments, the course ofaction is automatically entered into by the system 100, which controls amedical device 104. Accordingly, because the protocol 120 isautomatically triggered, step 508 may be skipped (e.g., because there isno time between eligibility and onset of the protocol 120). However, insome other embodiments, an indication (e.g., notification or alert) isprovided to the medical practitioner (e.g., via the user interface) thatthe patient 101 is eligible for the course of action. The medicalpractitioner may initiate the course of action by approving (e.g.,through the user interface) the automatic initiation of the course ofaction by the system, or by manually initiating the course of action.The patient 101 then enters the protocol 120. For example, the patient101 may be entered into the extubation readiness trial protocol 120. Insome embodiments, the protocol 120 may include the trigger 126 thatautomatically enters the patient 101 into the protocol 120.

After the course of action is initiated, the protocol trigger module 116communicates with the compliance module 110 to begin tracking patientcompliance with the protocol 120. In some embodiments, the trigger 126automatically activates the compliance module 110. Alternatively, theprotocol trigger module 116 is instructed by the medical practitioner(e.g., through approval or manual input to the user interface) toinstruct the compliance module to begin tracking data.

The process then proceeds to step 512, which tracks the dynamicconcordance of patient 101. As mentioned previously, dynamic concordancerate is the rate at which patient physiological data is consistent withthe compliance rules 124 of the protocol. As shown in the example ofFIG. 7, the protocol 120 may include one or more compliance rules 124.In the example of FIG. 7 the compliance rules include: (1) SpO2 isgreater than 88%, (2) Tidal Volume is greater than 5 ml/kg, (3)(EtCo2-EtCo2@ baseline)/EtCO2@baseline is less than 1.2, (4)(HR-HR@baseline)/HR@baseline is less than 1.2, and (5) the patient is onpressure support ventilation. If any of these conditions is notsatisfied, then the entire protocol 120 may be said to be not incompliance. The quality reporting module 114 tracks the duration andtimes during which the protocol 120 is not in compliance to determinethe dynamic concordance rate.

For the sake of an example, the calculation of a dynamic condition suchas heart rate at baseline is described. When the protocol is triggered,either manually or automatically, the system 100 takes the average ofthe measure in some period leading to the trigger. This period may be,for example, over 1 minute, 1 hour, or 2 hours prior to the trigger. Invarious embodiments, this average constitutes the baseline. The medicalpractitioner receives the baseline computed by the system 100 (e.g., viathe user interface 116) and may adjust the baseline value given theprovider's preference or the patient condition specifics (e.g., via theuser interface 116). In various embodiments, the system 100 may trackvarious patient parameters for a pre-determined time and automaticallycompute patient baseline parameters.

In some embodiments, the system 100 determines that the patient 101 isbelow a threshold concordance rate for the protocol 120. The system 100may provide an indication (e.g., through a notification or alert) to themedical practitioner that the patient is below the threshold concordancerate, and/or that dynamic concordance is trending downward. Theindication prompts the medical practitioner to check on or reevaluatethe patient 101 to identify and mitigate reasons for non-compliance.

The medical practitioner may then review the longitudinal data in theuser interface 116 and diagnose the reasons for noncompliance. Ifappropriate and possible, the medical practitioner may take anintervening action to cause the dynamic concordance rate to increase. Asa nonlimiting example, a patient under care for Acute RespiratoryDistress Syndrome may be ventilated according to a protocol requiringTidal Volume less than 7 ml/kg and peak inspiratory pressure less than30 mm Hg. A decreasing concordance rate indicates that one of theseconditions is not met. The system 100 sends a notification to themedical practitioner informing them of the decreasing concordance rate.The practitioner can review that data to identify which condition is notmet, and adjust the ventilation setting to provide optimal ventilationwith lower risk for lung injury and respective better expected patientoutcome.

FIG. 8 shows a user interface for tracking compliance with the protocol120. The plurality of patient data tracked in real-time is shown for thepatient 101. In the example of FIG. 8, HR, SpO2, TV, and etCO2 aretracked. Illustrative embodiments may track compliance at the parameterlevel. Furthermore, the user interface 112 may be configured to displaynon-compliant periods 140 (e.g., represented by shaded areas of thepatient data).

FIG. 9 schematically shows an interface for showing protocol complianceand time on protocol 120 for a plurality of patients 101 in accordancewith illustrative embodiments of the invention. As shown, some patients101 may be eligible or actively engaged in one or more protocols (e.g.,ARDS and ERT protocols 120). Additionally, the interface 112 may showprotocol duration (e.g., 1 hour and 15 minutes for Flintstone, Wilma) aswell as eligibility duration (e.g., 3 hours for Bunyan, Paul). Theinterface may also show the overall concordance rate for completedand/or active protocols.

Illustrative embodiments may provide periodic reporting to assistmedical practitioners with understanding facility wide compliance. FIG.10 schematically shows a report generated by the quality reportingmodule 114 showing facility wide compliance with protocols in accordancewith illustrative embodiments of the invention. The report may includeinformation relating to the percentage of eligible patients that areenrolled in the protocol, the overall compliance, the success rate, thenumber of enrolled patients over time, a summary of the parameters thatled to non-compliance, the average duration of compliance, and the meantime to enrollment, among other things. Accordingly, the information inthe report may be used to help improve patient 101 treatment over time,and also to let the medical practitioner track what areas/parametersneed to be monitored more closely for optimal clinical outcomes. Afterthe protocol is completed (e.g., the patient is successfully extubated)or otherwise concluded, the process 500 then comes to an end.

Although not explicitly shown in the process 500 of FIG. 5, it should beunderstood that throughout the process notifications may be provided torelevant medical staff. To that end, the patient tracking module 118 mayreceive the subscription rules 128 and the notification rules 130, aswell as patient status information from the protocol eligibility andcompliance module 110. As the rules 130 are met, the tracking module 118sends a notification to the various subscribed users in accordance withtheir subscription level. For example, notifications may be sent wheneligibility status is changed, when the course of action begins (alsoreferred to as protocol enrollment), and/or when the patient is out ofcompliance.

Furthermore, different subscription levels may receive differentnotification types. For example, “notification 1” may include a passivenotification, such as an alert through the user interface 112;“notification 2” may include an escalated passive notification, such asa text and/or an email; and “notification 3” may include an activenotification such as paging the medical staff.

Subscription rules 128 may be protocol based. Accordingly, a particularmedical practitioner may be subscribed to notifications for all patients101 on a particular protocol. Additionally, or alternatively,subscriptions may be patient-based. Patient-based subscribers receivenotifications relating to any and all protocols associated with a givenpatient 101. Illustrative embodiments also allow the medicalpractitioner to manually adjust or create notification protocols thatare not limited to protocol based or patient-based notifications.

Illustrative embodiments may communicate with a scheduling system (e.g.,hospital scheduling system) to determine which patient is under the careof which medical practitioner, and other information relating to themedical practitioner (e.g., unit, work schedule data, medicalspecialties, etc.). For example, the system may receive data indicatingthat patient John Smith may be under the care of bedside nurse Jackey,intensivist Dr Smith, and respiratory therapist Johnson. Accordingly,the notification system may receive appropriate information regardingwho to notify in accordance with the subscription rules 128.

Nested Protocols

FIG. 11 shows a process 1100 of nesting protocols in accordance withillustrative embodiments of the invention. It should be noted that thisprocess can be a simplified version of a more complex process that maynormally be used. As such, the process may have additional steps thatare not discussed. In addition, some steps may be optional, performed ina different order, or in parallel with each other. Accordingly,discussion of this process is illustrative and not intended to limitvarious embodiments of the invention. Finally, although this process isdiscussed with regard to entering a single patient in a medicalprotocol, the process of FIG. 11 can be expanded to cover processes forentering a plurality of patients in one or more medical protocols at thesame time. Accordingly, the process 1100 is merely exemplary of oneprocess in accordance with illustrative embodiments of the invention.Those skilled in the art therefore can modify the process asappropriate.

Steps 1102-1112 are substantially the same as steps 502-512 of FIG. 5,respectively, and therefore, discussion of these steps is not againrepeated in great detail. Steps 1102-1112 generally describe a processof determining whether a patient is eligible for a first protocol, andtracking the dynamic concordance rate of the patient after a course ofaction of the protocol begins.

FIG. 12 schematically shows an example of nested medical protocolshaving a variety of eligibility rules, compliance rules, and a protocoltrigger in accordance with illustrative embodiments. As shown in theexample of FIG. 12, the eligibility rules 122 of the ventilation weaningprotocol 120B are dependent upon a particular outcome from theventilation protocol 120A. For the sake of discussion, the dependentprotocol 120E may be referred to as the child protocol 120B. Whereas theprotocol 120A, upon which the child protocol 120B depends, may bereferred to as a parent protocol 120A. Despite the use of thisnomenclature, it should be understood that a child protocol 120B mayitself in turn be a parent protocol for a different protocol (e.g., athird protocol 120C). Furthermore, although not shown in this example, achild protocol 120B may have multiple parent protocols 120A upon whichit depends. In a similar manner, a parent protocol may have multiplechild protocols, with each child triggered by different conditionsassociated with the parent protocol (e.g., different dynamic concordancerates may trigger different child protocols).

In a manner similar to the previously described protocol 120 of FIG. 6,each of the protocols 120A-120C in FIG. 12 has a respective set ofeligibility rules 122, a course of action or trigger 126, and compliancerules 124. In the process of FIG. 11, steps 1102-1112 may relate to, forexample, the first protocol 120A.

At step 1110, the course of action (e.g., ventilation) begins when theeligibility rules 122 of the first protocol 120A are satisfied. Afterthe course of action begins, the dynamic concordance rate for thevarious compliance rules 124 is tracked at step 1112.

Step 1114 receives the eligibility rules 122 and the compliance rules124 for the second protocol 120B. Although step 1114 is shown asoccurring after step 1112, in practice, this step may occur earlier inthe process 1100 (e.g., simultaneously with 1102).

At step 1116, the process receives patient data, which includes thedynamic concordance rate of the first protocol 120A (also referred to asthe parent protocol). At step 1118, the process 1100 determines if thepatient is eligible for the second protocol. Step 1118 compares thereceived data from step 1116 with the eligibility rules 1222 for theprotocol 120B. Among other things, the eligibility rules 122 for thechild protocol 120B (the nested protocol) may include the dynamicconcordance rate from another protocol (e.g., the parent protocol 120A).In illustrative embodiments, the system 100 enables the use of nestedprotocols by keeping track of the status of each protocol 120A-120C andcontinuously calculating dynamic concordance rate.

In the example of FIG. 12, the second protocol 122 requires a 90% orgreater dynamic concordance for more than 3 hours for the ventilationprotocol 120A. The system 100 tracks all of the relevant data relatingto the compliance 124 of the first protocol 120A, and calculates thedynamic concordance rate. Although the eligibility rules show a relianceonly on a single parent protocol (i.e., the ventilation protocol 120A),it should be understood that eligibility rules 122 for a protocol mayinclude dynamic concordance rates (or other variables) from multipleother protocols. Thus, a single child protocol 120B may have multipleparent protocols 120A.

Additionally, illustrative embodiments enable the use of various nestedeligibility rules 122 and/or compliance rules 124. For example, rules122 and 124 may rely on an overall dynamic concordance rate for one ormore parent protocols 120A, a dynamic concordance rate for a most recentperiod of time (e.g., 90% or greater for the most recent 3 hours) forthe one or more parent protocols 120A, a total minimum time abovethreshold dynamic concordance rate (e.g., 2 hours above threshold, 1hour below threshold, and 1 hour above threshold), and/or a dynamicconcordance rate that is a function of a plurality of parent protocols120A (average dynamic concordance rate for plurality of parent protocols120A is above a given threshold). Various embodiments may includeBoolean operators in the eligibility rules 122 and/or the compliancerules 124 (e.g., “and,” “or,” “not”).

Returning to FIG. 11, after determining that the patient 101 is eligiblefor the second protocol 120B, the process 1100 proceeds to step 1120,which begins tracking eligibility time for the second protocol 120B. Ina manner similar to step 1108, step 1118 provides a quantitativemeasurement of hospital staff performance, and also provides the medicalpractitioner with information which may be used to prioritize thetreatment of patients in the unit (and/or the medical practitioner'sattention to a particular patient).

Although not explicitly shown, throughout the process of FIG. 11notifications may be sent to medical staff in accordance withsubscription rules 128 and the notification rules 130 of the protocol.For example, notifications of patient eligibility for the secondprotocol are sent to responsible hospital staff. Illustrativeembodiments advantageously reduce unnecessary pending eligible time toinitiation for patients 101 eligible for the second protocol.Furthermore, illustrative embodiments advantageously enable the user ofdynamic concordance rates from the first protocol 120A as an eligibilityrequirement for the second protocol 120B.

The inventors believe that both of these features (i.e., reduced pendingeligibility time, and focus on concordance rate based outcomes) lead toenhanced patient outcomes. The reason is that they enable the medicalpractitioner to provide care, which keeps the patient on the optimalprogression path thus reducing time in the ICU and recovery. In theexample from FIG. 11, the patient is intubated earlier by a timelynotification that the patient is eligible for ventilation. Theventilation dynamic concordance rate enables the medical practitioner tolongitudinally track whether the patient is receiving optimalventilation and oxygenation, and to intervene in a timely manner ifnecessary. Expedited intervention reduces the risk for end-organfailure. After the patient is stabilized, the system 100 prompts thepractitioner to start weaning, which effectively mitigates the risk ofthe patient 101 spending too much time on ventilation and experiencingventilator associated lung injury. This further impacts the timelinessof downstream child protocols, such as the ERT protocol. The system 100allows the clinician to know how much time the patient 101 may have beeneligible for a particular protocol (e.g. the extubation trial), thusurging them to start the protocol. After the trial is completed, thesystem 100 provides the dynamic concordance rate to the whole clinicalteam during rounds or other patient care planning activity so they maytimely make a decision for initiation of another protocol and/or courseof action (e.g., extubation).

At step 1122, the course of action of the second protocol 120B begins(i.e., the patient 101 is enrolled in the protocol). After the secondprotocol 120B begins, dynamic concordance of the patient is tracked. Theprocess then proceeds to step 1126, which asks if there are moreprotocols. If the answer is yes, then more patient data is received.Returning to the example of FIG. 12, a third protocol 120C haseligibility rules that relate an earlier protocol 120B. Accordingly,steps 1114-1124 are repeated for the third protocol 120C. This processmay be repeated for as many protocols as necessary. Eventually, whenthere are no additional nested protocols, the process comes to an end.

Hidden State Variables

Various protocols 120 may include eligibility rules 122 and/orcompliance rules 124 may include conditions (e.g., true or false, acertain variable is greater than a particular value, etc.) thatreference hidden state variables. As described further below, thesehidden state variable conditions 125 calculate a risk that a particularcondition is present, as opposed to directly measuring the condition.Thus, while steps 1104 and 1116 describe receiving patient data, thispatient data may also include a calculated hidden state variable whichis a function of measured patient data. Details of calculating riskprobabilities for certain patient conditions are described in furtherdetail in co-pending U.S. Patent Application No. 63/091,427, which isincorporated herein by reference in its entirety.

Interface

In hospital settings it is likely that medical staff are in charge of aplurality of patients 101. There, illustrative embodimentsadvantageously provide an intuitive user interface for management ofpatient protocols by the medical practitioner.

FIG. 13A schematically shows an interface 112 for viewing patientprotocol 120 information in accordance with illustrative embodiments.The patient's 101 medical event history, as well as ongoing protocol,completed protocol, and/or protocol eligibility history can be viewed bythe medical practitioner in the interface 112. Among other things, theinterface may show the patient bed number, name, status, medical recordnumber, sex, age, recent activity, map activity 132, and/or otherparameter values.

Illustrative embodiments provide a single user interface 112 configuredto display patient information relating to a plurality of patients 101.The plurality of patients 101 can be all of the patients 101 on aparticular hospital floor, in a particular hospital unit, associatedwith a particular protocol 120, and/or under the care of a particularmedical practitioner. In the same user interface 112, the protocolactivity 132 for each patient 101 is shown and described. For example,patient 101A is shown as being eligible (e.g., eligibility icon 131) foran ERT protocol 120 and the eligibility time (i.e., 1 day and 17 hoursfor patient 101A). Patient 101B is shown as having completed an ERTprotocol 120 (e.g., completed icon 133) and the total time of thecompleted protocol (i.e., 2 hours and 0 minutes for patient 101B).Patient 101C is shown as currently being enrolled/on-going (e.g.,enrollment icon 137) in an ERT protocol 120, and the total time thepatient 101C has been on the protocol (i.e., 1 hour and 19 minutes forPatient 101C).

As shown in FIG. 13A, optionally illustrative embodiments may displaythe amount of time the patient 101 has been or was on the protocol 120,as well as a dynamic concordance rate 135. Furthermore, illustrativeembodiments may include a dynamic concordance indicator icon 139 thatindicates whether the dynamic concordance rate has been trending up(e.g., green arrow icon 139A), trending down (e.g., red arrow icon139B), or is steady within a pre-defined timeframe (e.g., horizontalgreen arrow 139C if the overall concordance is above a threshold orhorizontal red arrow 139D if the overall concordance is below thethreshold).

The system 100 may visually indicate completed protocols with a checkmark on the user interface 116. These visualization enable simplifytransfer of clinical care from one medical practitioner to another, andtherefore, lead to better patient outcomes. For example, extubationdecisions are usually made by the care team during morning rounds basedon extubation readiness trials completed during the previous shift. Therounding team can review which patients have had completed ERTs and thenmake decision to extubate all patients with high overall concordance.The longitudinal data for patients with lower concordance can bereviewed in more detail to determine reason for noncompliance and assesswhether this reason indicates unacceptable risk for extubation failure.Furthermore, in practice, by the time the protocol 120 is complete, itis possible that the medical practitioner that was in charge of thepatient may have changed shifts. Illustrative embodiments providevisualizations that simplify prioritization for medical care of patientsfor subsequent clinicians.

FIG. 13B schematically shows an interface 112 for viewing patientprotocol 120 information in accordance with illustrative embodiments inaccordance with illustrative embodiments. The interface of FIG. 13B issubstantially identical to the interface of FIG. 13A, with the additionof an interface eligibility menu 907 feature having a plurality ofactions related to the patient being eligible for the particularprotocol. In some embodiments, the medical practitioner may manuallyselect that the protocol has started so the system starts trackingcompliance. In some other embodiments, the system may automaticallydetect that the user has been placed on the protocol and start trackingcompliance.

The eligibility menu 907 provides a number of useful functions to themedical practitioner within the interface 112 that simplifies managementand/or treatment of the patient on the protocol. For example, the menumay include an adjust parameters button 908 that provides medicalpractitioners with the ability to adjust the parameters related toprotocol compliance and/or eligibility. The menu may also include asnooze eligibility button 909 that allows the medical practitioner tosnooze eligibility (and therefore delay or stop notifications regardingeligibility and/or tracking of time since eligibility). For example, themedical practitioner may, in their medical judgment, believe thatalthough the patient parameters are within limits, that the patientshould still not be placed on the protocol. For example, the patientparameters may show that the patient is on minimal ventilation settingsindicating eligibility for ERT, but physical examination may indicatethat the patient does not have a coughing reflex, which leads thepractitioner to snooze eligibility for a predefined period of time.Furthermore, an exclude button 910 provides medical practitioners withthe ability to completely exclude a patient from a particular protocol.For example, if the patient is on chronic ventilation, the patient maynot be extubated at all in that particular unit. These features help themedical staff manage notifications that may otherwise be sent and/orstop tracking inaccurate quality information.

Although the features described in FIG. 13A and 13B are shown inseparate screenshots, it should be understood that all of the featuresdiscussed therein may be combined.

FIG. 13C schematically shows the user interface 112 of FIGS. 13A and 13Bin accordance with illustrative embodiments of the invention. Themedical practitioner may click on the dynamic concordance rate 135 clinto display a new compliance box 920 that the compliance of theindividual parameters that determine the concordance rate. In theparticular example shown, two of the parameters informing theconcordance rate (IDO2 and IVCO2) are risks of hidden internal statevariable being in particular states.

FIG. 13D schematically shows the protocol 120 as an overlay in theinterface of FIG. 13A. A user input into the interface 112 causes thesystem 100 to display the eligibility rules 122 and/or the compliancerules 124 for the selected protocol 120 (e.g., user selects the protocol120 name “ERT”). For example, the patient 101B is on an ExtubationReadiness Trial. The eligibility rules 122 shown are: the patient inspontaneously breathing, PEEP<=7 cmH2O, and FiO2<=50%. The compliancerules 124 shown are: SpO2>=goal SpO2, normalized TV>5 mL/kg, RR notincreased by 20% above baseline RR, and HR not increased by 20% abovebaseline Hr.

Returning to the census view of FIG. 13A, a user input into theinterface 112 causes the system 100 to display the relevant receiveddata for the selected protocol 120 (e.g., user selects the amount oftime patient is eligible, the amount of time the patient is on theprotocol, and/or the dynamic concordance rate 135).

FIG. 13E schematically shows the received patient data that relates to aselected protocol 120 in FIG. 13A. Accordingly, the user interface 112no longer shows the census view of the plurality of patients 101, butinstead displays data relevant to a particular selected patient 101B. Inparticular, because the patient 101B has already completed the protocol120 (e.g., ERT), the user interface 112 displays patient data relatingto compliance rules 124. In a similar manner, if the patient iscurrently on the protocol 120, the user interface 112 displays patientdata relating to the compliance rules 124. Alternatively, if the patient101 is eligible for the protocol 120, the user interface 112 displayspatient data relating to the eligibility rules 122.

The received patient data is continuously streamed (ornear-continuously) streamed from the sensors 102 and/or peripheraldevices 104, such that data points are collected. As shown in FIG. 13D,the example protocol has compliance rules 124 that relate to SpO2,normalized tidal volume (TV normalized in mL/kg), respiratory rate, andheart rate. Thus, the user interface 112 in FIG. 13E displays all thedata that is relevant to the compliance rules 124. The user interface112 shows non-compliant periods 140 in a visually distinguishable way(e.g., represented by shaded areas of the patient data). Advantageously,a medical practitioner may view all of the relevant patient datarelating to the protocol 120 (e.g., compliance rules 124 and/oreligibility rules 122), and problematic patient data is visuallyemphasized. A dynamic concordance rate (e.g., 67%) is calculated thatdetermines the amount of time the patient 101 has been in complianceover the length of the completed protocol (e.g., 2 hours). However, inongoing protocols, the dynamic concordance rate is calculated for thetime the protocol has been ongoing.

Additionally, the user interface 112 may display a protocol startindication 899 indicating the start time of the protocol relative to thedisplayed data. In a similar manner, illustrative embodiments maydisplay a protocol end indication 900 indicating the end time of theprotocol relative to the display data. The user interface 112 mayinclude a user-selectable marker 901 adjacent to the protocol startindication 899. By selecting the marker 901, the interface 112 displaysa text box 902 that has information relating to the exact time of theprotocol and/or the computed baselines at the beginning of the protocol(e.g., against which the patient 101B is evaluated). If desired, themedical practitioner can select an update icon 903 to update thebaselines either before, during, or after the protocol.

FIG. 13F schematically shows an overlay window 910 that displays in theuser interface 112 when the update icon 903 is selected in accordancewith illustrative embodiments. A baseline heartrate 904 is automaticallycalculated based on the average of a time period (e.g., 1 minute, 2minutes, 1 hour, or 2 hours) before the start of the protocol 120. Thissets the baseline parameter. However, overwrite box 905 allows a medicalpractitioner to overwrite these parameters and put in new parameters(e.g., if the practitioner believes that a protocol 120 using a baselineparameter has a baseline that is not sufficient for the protocol 120).Furthermore, other parameters 906 may be manually entered or overwrittenby a medical practitioner.

FIG. 13G schematically shows a time stamp of selected data for aparticular moment of FIG. 13E. As indicated by the time-stamp line 136,the particular patient data values at a particular moment may be viewed.Furthermore, the influence of internal state variables on a patient'sclinical risk is also visualized. For example, FIG. 13G shows the impacton a patient's clinical risk of low IVCO2 based on measured heart rate,respiratory rate, and rSO2.

In this example, while the IVCO2 index is not part of the particularprotocol, it is provided for added context. This is a feature of thesystem where not all of the trends that are associated with a particularprotocol view are rules. Some of them are displayed to provide contextand facilitate the interpretation of why the rules are violated.

Although IVCO2 is shown as an example of a hidden state variable, theprinciples apply to any display of clinical risk and its associatedinternal state variable. As shown, FIG. 3D depicts one embodiment of thedisplay of the influence of an internal state variable or measurement ofan internal state variable on a patient's clinical risk. The userinterface 112 shows the clinical risk plotted as a bar graph vs time atthe top of the figure, as well as the monitored measurements for thepatient plotted vs time below the risk bar graph. When the user hoversover the clinical risk graph 871, the measurements or ISVs that arecontributing to the clinical risk level at that time are displayed in abox 879. The box 879 in the figure displays a non-limiting example ofthe top three contributing factors listed in order based on the amountof influence each contributor has had on the displayed risk level. Byscrolling alone the time-axis, the top 3 contributing factors may changefrom time to time. Furthermore, some embodiments may display more than 3or fewer than 3 contributing factors.

FIGS. 13A-13G provide a user interface 112 that may be displayed in anumber of ways. For example, the interface 112 may be provided on anyconventional interface (e.g., a monitor, touch-screen display, etc.).Additionally, the interface 112 may be stored on a server that can beco-located in the hospital network, or that can be remotely access(e.g., from the cloud). In some embodiments, a dedicated device maydisplay the user interface 112. The device may have a touch-screendisplay, wireless internet connectivity, and/or may be configured tomount to a hospital bed.

It should be understood that illustrative embodiments advantageouslyenable a number of improved medical care applications, and furthermoreprovide improved medical outcomes that would otherwise not be possiblewithout the real-time tracking of patient parameters. Thestate-of-the-art checks patient parameters statically, (e.g., on aparticular patient schedule or based on a medical practitionerschedule). However, the inventors determined that patient clinicaloutcomes are far improved when eligibility time is reduced, and/or whendynamic concordance rate is maintained at a high level. By havingreal-time visualization of the eligibility time and/or the dynamicconcordance rate, patients may more quickly enter an eligible protocol,and may also be treated more quickly to help keep dynamic concordancerate high. Furthermore, the specific issues with dynamic concordancerate may be visualized in real-time and specific low complianceparameters may be easily determined by medical practitioners.

There are a large number of protocols which may be implemented byillustrative embodiments of the invention. Non-limiting examples ofprotocols include:

-   -   Ventilation of patients with Acute Respiratory Distress        Syndrome. Eligibility criteria may be defined by SF (SpO2/FIO2)        or PF (PaO2/FIO2) ratio being below 300. Compliance may be        defined by specific parameters indicting appropriate ventilator        settings, e.g:        -   Tidal Volume below 8 ml/kg        -   peak respiratory pressure below 30 cmH2O    -   Weaning of Vasoactive Support. Eligibility criteria may be        defined by a low risk for the patient being in an inadequate        oxygen delivery state as assessed by the system and method in        U.S. patent application Ser. No. 17/033,591, which is        incorporated herein by reference in its entirety. After        initiating of weaning of Vasoactive Support compliance may be        defined as:        -   Rate of VIS score decrease for each consecutive hour being            above a given threshold        -   Risk for inadequate oxygen delivery not being above a given            threshold        -   Mean arterial blood pressure not decreasing below a patient            and age specific threshold        -   Lactate not increasing above 4 mmol/L

As referenced previously, various protocols 120 may include eligibilityrules 122 and/or compliance rules 124 may include conditions (e.g., trueor false, a certain variable is greater than a particular value, etc.)that reference hidden state variables. Details of calculating riskprobabilities for certain patient conditions are described in furtherdetail in co-pending U.S. Patent Application No. 63/091,427, which isincorporated herein by reference in its entirety.

Various embodiments of the invention may be implemented at least in partin any conventional computer programming language. For example, someembodiments may be implemented in a procedural programming language(e.g., “C”), as a visual programming process, or in an object orientedprogramming language (e.g., “C++”). Other embodiments of the inventionmay be implemented as a pre-configured, stand-along hardware elementand/or as preprogrammed hardware elements (e.g., application specificintegrated circuits, FPGAs, and digital signal processors), or otherrelated components.

In an alternative embodiment, the disclosed apparatus and methods (e.g.,see the methods described above) may be implemented as a computerprogram product for use with a computer system. Such implementation mayinclude a series of computer instructions fixed either on a tangible,non-transitory, non-transient medium, such as a computer readable medium(e.g., a diskette, CD-ROM, ROM, or fixed disk). The series of computerinstructions can embody all or part of the functionality previouslydescribed herein with respect to the system.

Those skilled in the art should appreciate that such computerinstructions can be written in a number of programming languages for usewith many computer architectures or operating systems. Furthermore, suchinstructions may be stored in any memory device, such as semiconductor,magnetic, optical or other memory devices, and may be transmitted usingany communications technology, such as optical, infrared, microwave, orother transmission technologies.

Among other ways, such a computer program product may be distributed asa removable medium with accompanying printed or electronic documentation(e.g., shrink wrapped software), preloaded with a computer system (e.g.,on system ROM or fixed disk), or distributed from a server or electronicbulletin board over the network (e.g., the Internet or World Wide Web).In fact, some embodiments may be implemented in a software-as-a-servicemodel (“SAAS”) or cloud computing model. Of course, some embodiments ofthe invention may be implemented as a combination of both software(e.g., a computer program product) and hardware (e.g., a processor).Still other embodiments of the invention are implemented as entirelyhardware, or entirely software.

Although the above discussion discloses various exemplary embodiments ofthe invention, it should be apparent that those skilled in the art canmake various modifications that will achieve some of the advantages ofthe invention without departing from the true scope of the invention.

What is claimed is:
 1. A system for determining patient eligibility andcompliance with a medical protocol, the system comprising: a medicalprotocol library containing information relating to a plurality ofmedical protocols, the information including eligibility rules andcompliance rules for the plurality of medical protocols, the pluralityof medical protocols including at least one parent protocol and at leastone child protocol; a sensor and medical device interface configured toreceive patient data from one or more sensors and/or one or more medicaldevices, the patient data relating to the eligibility rules and/or thecompliance rules for at least one of the medical protocols; a protocoleligibility module configured to determine patient eligibility for theat least one parent protocol as a function of the received patient data;a user interface configured to display an indication that at least onepatient is eligible for the at least one parent protocol; and a protocolcompliance module configured to determine, after the at least onepatient enters the parent protocol, a dynamic concordance rate of the atleast one patient for the parent protocol as a function of the receivedpatient data and the compliance rules, wherein the dynamic concordancerate defines the rate at which the patient data is consistent with thecompliance rules of the parent protocol, wherein the protocoleligibility module is further configured to determine patienteligibility for the at least one child protocol as a function of thedynamic concordance rate of the at least one parent protocol, the userinterface being further configured to display the dynamic concordancerate of the parent protocol for the at least one patient.
 2. The systemas defined by claim 1, further comprising a quality reporting moduleconfigured to determine an eligibility time, wherein the eligibilitytime is the amount of time elapsed from when the at least one patient iseligible for the medical protocols to the time the at least one patientis entered into the medical protocol, wherein the user interface isfurther configured to display the eligibility time for the at least onepatient.
 3. The system as defined by claim 1, wherein the protocoleligibility module is configured to determine patient eligibility as afunction of a hidden state variable.
 4. The system as defined by claim1, wherein the eligibility rules for the child protocol include thedynamic concordance rate for the parent protocol.
 5. The system asdefined by claim 1, wherein the protocol eligibility module isconfigured to determine patient eligibility as a function of a patientelectronic medical record.
 6. The system as defined by claim 1, whereinthe user interface is configured to display, in response to a userselection of a selected patient, all of the received patient datarelating to the eligibility rules and/or the compliance rules of acorresponding protocol that the selected patient is on.
 7. The system asdefined by claim 6, wherein non-compliant portions of the received dataare visually distinguishable from compliant portions of the data.
 8. Thesystem as defined by claim 1, wherein the patient eligibility isdetermined as a function of meeting a plurality of conditions and/orpatient variables.
 9. The system as defined by claim 1, wherein themedical protocol is an extubation readiness trial protocol.
 10. A methodfor entering a patient in a medical protocol, the method comprising:receiving eligibility rules and compliance rules for a plurality ofmedical protocols, the plurality of medical protocols including a parentprotocol and a child protocol; receiving real-time patient data from oneor more sensors and/or medical devices, wherein the patient datadirectly or indirectly relates to the eligibility rules and/or thecompliance rules for the parent protocol and/or the child protocol;determining that the patient is eligible for the parent protocol as afunction of the eligibility rules and the real-time patient data fromthe one or more sensor and/or medical devices; indicating that thepatient is eligible for the parent protocol; calculating a dynamicconcordance rate for the parent protocol; determining that the patientis eligible for the child protocol as a function of the dynamicconcordance rate of the parent protocol.
 11. The method as defined byclaim 10, further comprising: entering the patient into the medicalprotocol after indicating that the patient is eligible for the protocol.12. The method as defined by claim 11, further comprising: displaying,on a user interface, a plurality of patients that are eligible for theprotocol and/or currently enrolled in the protocol; tracking a timesince the patient became eligible for the protocol and/or a time sincethe patient is enrolled in the protocol; tracking a dynamic concordancerate of the medical protocol; displaying, on the user interface, thetime since the patient became eligible for the protocol, time since thepatient is enrolled in the protocol, and the dynamic concordance rate ofthe medical protocol.
 13. The method as defined by claim 12, furthercomprising: displaying, in response to a user selection of a givenprotocol, the received patient data that relates to the eligibilityrules and/or the compliance rules for the selected protocol.
 14. Themethod as defined by claim 13, wherein the received patient data is usedto determine a hidden state variable.
 15. The method as defined by claim14, wherein the eligibility rules and/or the compliance rules for theselected protocol include a hidden state variable risk.
 16. The methodas defined by claim 11, wherein determining patient eligibility is afunction of a patient electronic medical record.
 17. The method asdefined by claim 10, further comprising displaying the indication thatthe patient is eligible for the protocol.
 18. The method as defined byclaim 11, wherein the medical protocol is an extubation readiness trialprotocol.
 19. A computer program product for use on a computer systemfor determining eligibility and compliance with a medical protocol, thecomputer program product comprising a tangible, non-transient computerusable medium having computer readable program code thereon, thecomputer readable program code comprising: program code for receivedeligibility rules and compliance rules for a plurality of medicalprotocols, the plurality of medical protocols including a parentprotocol and a child protocol; program code for receiving real-timepatient data from one or more sensors and/or medical devices, whereinthe patient data directly or indirectly relates to the eligibility rulesand/or the compliance rules for the parent protocol and/or the childprotocol; program code for determining that the patient is eligible forthe parent protocol as a function of the eligibility rules and thereal-time patient data from the one or more sensor and/or medicaldevices; program code for indicating that the patient is eligible forthe parent protocol; program code for calculating a dynamic concordancerate for the parent protocol; program code for determining that thepatient is eligible for the child protocol as a function of the dynamicconcordance rate of the parent protocol.
 20. A computer program productas defined by claim 19, further comprising: program code for displaying,on a user interface, a plurality of patients that are eligible for theprotocol and/or currently enrolled in the protocol; program code fortracking a time since the patient became eligible for the protocoland/or a time since the patient is enrolled in the protocol; programcode for tracking a dynamic concordance rate of the medical protocol;program code for displaying, on the user interface, the time since thepatient became eligible for the protocol, time since the patient isenrolled in the protocol, and the dynamic concordance rate of themedical protocol.